[Previous] [Next] [Index] [Thread]

Re: Java/Netscape security holes: hole du jour and summary

I'm sorry, I should have been more careful in what I said.  I meant:
"a use of a JavaScript bug to abuse HTTP file upload".  There is
nothing intrinsically wrong with upload that I've found.  Rather,
using JavaScript I was able to set the filename of an upload entry,
thus allowing files to be uploaded without the user's knowledge or
control.

If you look how JavaScript interfaces with forms you'll find that
they are exceptionally careful in what JavaScript code is and is
not able to do WRT file upload and password fields.  I.e., code is
prevented from reading or writing the actual path typed by the
user.  This actually works such that code could write a value into
entry's property, but this value is separate from the entry the
user types into, such that it is not displayed to the user nor used
for upload.

However, a bug in the implementation of the JavaScript interpreter
caused the resetting of a form to copy the value set by code onto the
value used by upload!  This allows one to write code that effectively
uploads any file it wants, such as /etc/passwd.

I have an exploit that does exactly this.  You can try it my JavaScript
problems page, http://www.osf.org/~loverso/javascript/.  Note that you'll
have to re-enable JavaScript in your Netscape browser to try this, and
you'll have to use 2.0 or 2.01.


Fortunately, another set of bugs in JavaScript prevented code from
automatically calling the form reset method.  These are that the
reset() method is not exported, and that the click() method was
unreliable on all their supported platforms, so they stubbed it
out (although it remains in the documentation; at least when I was
trying this out in Marc).  This meant that to exploit this bug,
you needed to entice a user to press a "reset" button a form.  This
is actually not that hard, since the visual difference in the
appearance of the reset and submit buttons is lost on many naive
users.

The other problem to workaround in successfully exploit this is
the visual difference with a file upload element, which has a big
"BROWSE" button next to the entry box..  In my exploit, you'll
notice I use the Netscape's frames non-feature of using an area
that can't be resized to hide the file upload entry box and it's
telltale BROWSE button.  You won't even see the upload box, and,
hence, you cannot tell what might happen when you press one of my
buttons.

I always thought it was odd that they didn't give code the ability
to reset(), but did give code the ability to submit().  Most of
the privacy problems have been dependent upon this once feature.


Please note that I've only just made this exploit available since
has released fixes in 2.02, which has just come out yesterday.
(Actually, it has been fixed since 3.0b2)

I've also made a second exploit available, a new version of the
"directory browser" (dated 3/18 on my page).  Netscape has fixed
this bug twice already, previously in 2.0b6 and then again in 2.01.
My latest approach used JavaScript code generated on-the-fly to fool
Netscape into believing that "file:/" has been loaded from the same
server as where you picked up my page, hence allowing my JavaScript code
to walk the list of link properties (and report back via a CGI).

John LoVerso
OSF Research Institute
References: